1. Field of the Invention
The present invention relates to the field of network communication and more particularly to a method for generating a secure association key (SAK), a method for realizing medium access control security (MACsec), and a network device.
2. Background of the Invention
The technique about the security of the network link layer is an important research subject for network communication, and the IEEE 802.1.ae task group has studied this subject, and proposed to ensure the security of Layer 2 communication through medium access control security (MACsec) so as to protect Layer 2 from being attacked. Particularly, the above MACsec manner includes the following steps. A sending MACsec entity (SecY) encrypts data to be sent with a secure association key (SAK), and then a receiving SecY receives the data and decrypts the data with the same SAK to obtain the data, thereby ensuring the confidentiality of the data. Meanwhile, by checking an integrity check value (ICV), the receiving SecY determines that the received data is consistent with the data sent by the sending SecY, thus ensuring the integrity and correctness of the data.
Currently, the IEEE 802.1.ae task group has specified that the MACsec is based on a local area network (LAN) in the protocols. If the SecYs intend to communicate with each other, they need to belong to the same secure connectivity association (CA), and the SecYs in the same CA own the same secure connectivity association key (CAK). The CAK may be configured manually or obtained from an authentication server after being authenticated. The SecYs negotiate with each other through the CAK to generate an SAK. The SAK varies and is updated continuously, but the CAK remains constant. Even if the device is rebooted, the CAK still remains constant. The continuous variation and update of the SAK greatly enhance the security of the data.
FIG. 1 is a schematic view of a communication among medium access control (MAC) devices in the same shared medium LAN in the prior art. Referring to FIG. 1, MAC devices A, B, C, and D are located in the same shared medium LAN, and the MAC devices can visit and communicate with each other. It is assumed that the MAC devices A, B, and C belong to the same CA and own the same CAK, except the MAC device D. As shown in FIG. 2, apparently, the SecYs on the MAC devices A, B, and C can carry out the secure MACsec communication. Unfortunately, as the MAC D does not have the SAK, even if capturing a MACsec frame sent from A, B, or C, the MAC D still cannot decrypt the frame.
The IEEE 802.1af task group further specifies the generation of the SAK. The SAK used by the SecYs is obtained from a MAC security key agreement entity (KaY). One KaY may include one or more key selection protocol (KSP) instances, among which one KSP instance corresponds to one SecY, and they all own the same CAK. One KSP instance negotiates with the other KSP instances belonging to the same CA by using the CAK so as to obtain the SAK, and then submits the SAK to the SecYs that belong to the current CA. The data packets received and sent by the KSP instance are forwarded via the KaY corresponding to the current KSP instance. That is to say, when the KSP instance needs to send a data packet to a link, it first sends the data packet to a corresponding KaY, and then the KaY forwards the data packet to the link.
The SAK is generated through interactive communication of a key selection protocol data unit (KSPDU) by using a KSP protocol. FIG. 3 is a schematic view of a KSPDU frame format. A destination MAC address of a KSPDU frame is a multicast address, so that all the MAC devices in the same LAN can receive the KSPDU. The bridge does not forward the KSPDU, but filters out the KSPDU, so as to limit the KSPDU within the same LAN, thus achieving the MACsec communication within the LAN.
However, as the current key agreement techniques are all directed to the LAN, all the SecYs belonging to the same CA need to be located in the same LAN, and accordingly the data protection through the MACsec can only be realized hop by hop, that is, it requires encryption and decryption at each link. Referring to FIG. 4, as for a network system formed by bridges, an encrypted communication frame sent between a user terminal A and a user terminal B can be decrypted at a bridge 1, a bridge 2, and a bridge 3, so as to read a user data, which poses a great threat to the security of the user data. Especially, when the bridges in the middle are not managed by the user himself/herself, the security and confidentiality of the user data cannot be guaranteed at all.